1/1 


RD-A156  881 
UNCLASSIFIED 


SARSAT  LUC  (LOCAL  USER  TERMINAL)  TO  CMCC  (CANADIAN 
MISSION  CONTROL  CENTRE.  <U>  DEFENCE  RESEARCH 
ESTABLISHMENT  OTTAWA  (ONTARIO)  W  R  MCPHERSON  ET  AL. 
DEC  84  DREO-TN-84-24  F/G  17/2 


NL 


MICROCOPv  RESOLUTION  TEST  CHART 

V-‘ ■  W  u>>oi  i  ft 


/ 


►  National 
Defence 


□dense 

national 


iTfBWWfaST* 


'•  .  -1 


SARSAT  LUT  TO  CMCC  ALERT  DATA  INTERFACE 

A  CRITICAL  REVIEW 

by 

W  R.  McPherson  and  S.Y.  Slinn 


%  JUL  2  3  1335 


A 


DEFENCE  RESEARCH  ESTABLISHMENT  OTTAWA 

TECHNICAL  NOTE  84-24 


anad'a 


*5 


i 


December  1964 
Ottawa 


12  057 


National  Defense 
Defence  nationale 


SARSAT  LUT  TO  CMQC  ALERT  DATA  INTERFACE 

A  CRITICAL  REVIEW 

by 

W.R.  McPherson  and  S.Y.  Slinn 
SARSAT  Project  Office 
Electronics  Division 


PCN 

33X00 


DEFENCE  RESEARCH  ESTABLISHMENT  OTTAWA 

TECHNICAL  NOTE  84-24 


December  1984 
Ottawa 


n 


ABSTRACT 


The  transfer  of  beacon  alert  data  from  the  SARSAT  Local  User 
Terminal  (LUT)  to  the  Canadian  Mission  Control  Centre  (CMCC)  has 
shortcomings.  A  critical  review  of  the  transfer  of  information  between 
these  two  SARSAT  facilities  was  undertaken.  As  a  result  of  this  review,  a 
recommended  LUT  to  CMCC  data  flow  methodology  has  been  developed, 
characterized  and  evaluated.  Implementation  of  the  recommendations 
outlined  should  improve  the  operational  usefulness  of  the  SARSAT  system. 


RESUME 


Le  transfert,  depuis  la  station  terrestre  a  utilisation  locale 
(LUT)  au  Centre  canadien  de  control e  des  missions  (CCCM),  des  donnees 
d'alerte  emises  par  les  balises  presente  des  lacunes.  On  a  fait  un  ex^men 
critique  du  transfert  de  donnees  entre  deux  installations  du  SARSAT.  A  la 
suite  de  cet  examen,  une  methode  applicable  au  flux  de  donnees  entre  LUT  et 
CCCM  a  ete  mise  au  point,  defini  et  evaluee.  Grace  aux  recommandations 
formulees,  l'utilite  operationel le  du  SARSAT  devrait  etre  accrue. 
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1.0  INTRODUCTION 


The  transfer  of  beacon  alert  data  from  the  SARSAT  Local  User 
Terminal  (LUT)  to  the  Canadian  Mission  Control  Centre  (CMCC)  has 
shortcomings.  On  the  one  hand,  t  e  LUT  provides  alert  datg__.qual  ity 
indicators  which  during  the  SARSAT  Demonstration  and  Evaluation'TD&E)  have 
been  demonstrated  to  be  inadequate,  while  on  the  other  hand,  it  retains 
data  descriptors  which  are  required  by  operational  personnel. 

The  purpose  of  this  report  is  to  critically  review  data  available 
at  the  LUT,  determine  its  operational  utility  and  outline  a  definition  of 
transfer  from  the  LUT  to  the  CMCC.  The  potential  impact  of  implementing 
this  definition  will  be  assessed  with  the  aid  of  historical  data. 


The  subject  work  is  documented  in  terms  of  the  background  to  the 
problem,  an  outline  of  approach  and  analytical  tools  developed,  validation 
of  the  approach,  summary  comments  and  recommendations.  -  J 
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2.0  BACKGROUND 


As  background  to  the  presentation  of  the  development  work 
undertaken  at  DREO,  the  SARSAT  concept  and  its  available  facilities  are 
briefly  discussed.  This  is  followed  by  a  brief  description  of  the  current 
data  transfer  definition  between  the  LUT  and  CMCC.  With  this  background 
established,  the  current  operational  problems  associated  with  this  data 
transfer  are  discussed. 


2.1  SARSAT  Facility  Overview 


The  basic  concept  of  the  SARSAT  satellite-aided  search  and  rescue 
mission  is  illustrated  in  Figure  1.  The  signals  radiated  by  an  emergency 
beacon,  either  an  Emergency  Locator  Transmitter  (ELT)  or  an  Emergency 
Position  Indicating  Radio  Beacon  (EPIRB),  are  detected  by  a  polar-orbiting 
spacecraft  equipped  with  suitable  receivers.  These  signals  are  then 
relayed  to  a  LUT  where  the  signals  are  processed  to  determine  the  location 
of  the  ELT  or  EPIRB.  The  fact  that  an  alert  has  been  detected,  along  with 
the  location  of  the  ELT  or  EPIRB,  is  then  relayed  to  an  appropriate  Rescue 
Coordination  Centre  (RCC)  for  initiation  of  the  search  and  rescue 
activities. 


FIGURE  1:  Basic  Concept 


Doppler-positioning  techniques  which  use  the  relative  motion 
between  the  spacecraft  and  the  ELT/EPIRB  were  considered  as  a  practical 

means  of  locating  these  very  simple  devices.  All  that  is  required  is  that 
the  ELT/EPIRB  emit  a  carrier  frequency  with  a  reasonable  stability  during 
the  period  of  mutual  ELT/EPIRB-satel 1 ite  visibility.  To  optimize 
Doppler-positioning  performance,  satellites  in  a  low-altitude  polar  orbit 
are  used.  The  low  altitude  results  in  low  ELT/EPIRB  power  requirements, 
good  Doppler-shi ft  characteristics  and  short  time  delays  between  successive 
passes.  The  use  of  polar  orbits  results  in  coverage  of  the  whole  earth. 

Within  the  context  of  the  current  discussion,  the  SARSAT  system 
consists  of  the  following  three  subsystems: 

•  The  first  subsystem  is  the  ELT  and/or  EPIRB.  These  small 

emergency  transmitters  are  designed  to  transmit  distress 
signals  in  the  121.5  and  243  MHz  bands. 

•  The  second  subsystem  is  the  spacecraft  (SARSAT  and/or  COSPAS) 
which  receives  these  signals  and  retransmits  them  at  1544.5 
MHz  to  a  ground  station  for  processing. 

•  The  third  subsystem  is  the  Local  User  Terminal  (LUT),  which  is 

the  ground  station  that  receives  the  relayed  distress  signals. 

These  signals  are  processed  within  the  LUT  to  establish  a 
beacon  position  location  which  is  then  transmitted  to  a 
Mission  Control  Centre  (MCC). 

The  work  being  discussed  herein  is  focused  within  the  third 
subsystem  .  Specifically,  the  problem  being  addressed  is  associated  with 
the  definition  of  the  transfer  of  distress  data  from  a  LUT  to  the  Canadian 
MCC. 


2.2  Current  Data  Transfer 


The  current  data  transferred  by  the  LUT  to  the  CMCC  for  each 
alert  detected  is  as  illustrated  in  Figure  2. 


Line  #  Content 

1  121.5  ELT -EPIRB/160/01612  LUT  10  1511715Z  81 

2  EN  02 

3  SPCRFT  ID  S02/0  NB  01135/DATA  SRC  LUT  10  OTTA 

4  PROC  COMP  002  1750Z  80 

5  LOC  A/LAT  52  22.5  N/LONG  045  36.5  E 

6  ERROR  EST  ANG  010/MAJ  12.3/MIN  04.5/PR0B  55 

7  LOC  B/LAT  51  31.3  N/LONG  047  22.4  E 

8  ERROR  EST  ANG  009/MAJ  12.6/MIN  04.7/PR0B  45 

9  QUALITY  FACTOR  123456 


FIGURE  2:  Sample  LUT-CMCC  121.5  ELT -EPIRB  Transfer  File 
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Data  provided  by  the  LUT  consists  of  descriptor  data,  e.g. 
spacecraft  identification,  date,  source,  event  times,  etc.,  the  location 
data  (real  and  image  locations),  error  estimates,  and  a  quality  factor. 

SARSAT  D&E  results,  using  LUT  data  operationally,  have  indicated 
that  quality  parameters  associated  with  the  estimate  of  beacon  location, 
i.e.  lines  6,  8  and  9  in  Figure  2,  do  not  meet  the  users  needs.  The  error 
ellipse  does  not  adequately  model  the  error  (an  empirical  scale  factor  of 
three  has  been  suggested  to  correct  this  inadequacy),  the  quality  factor 
has  only  limited  applicability,  and  the  probability  factor  does  not  have 
sufficient  sensitivity,  except  in  unusual  cases,  to  resolve  ambiguity. 

As  a  result  of  the  above,  the  end  user  of  the  SARSAT  data,  the 
CMCC  operator  and  ultimately  the  RCC  controller,  must  take  the  estimations 
of  beacon  location  at  their  "face  value",  and  action  all  data  provided  by 
the  system  in  the  same  way.  Work  at  DREO  suggests  that  through  better 
visibility  into  LUT  data,  operational  users  of  SARSAT  data  can  determine 
their  level  of  response  and  act  accordingly. 


2.3  Statement  of  the  Problem 


Therefore,  the  problem  existing  at  the  operational  level  is  one 
of  a  lack  of  qualifiers  being  provided  with  SARSAT  alert  data.  The  user  is 
forced  to  treat  all  SARSAT  data  in  the  same  manner.  The  CMCC  operators  and 
RCC  controllers  cannot  measure  their  response  to  the  alert  data  and  act 
accordingly.  The  end  result  of  the  above  is  that  operational  users  are 
unable  to  fully  benefit  from  the  SARSAT  system. 


3.0  OUTLINE  OF  APPROACH  AND 
ANALYTICAL  DEVELOPMENT 


The  problems  associated  with  the  LUT  data  and  the  inadequate 
guidance  being  given  by  the  SARSAT  system  to  the  users  was  realized  soon 
after  data  began  to  flow  in  1982.  It  has  been  discussed  many  times  in 
numerous  different  forums  over  the  past  few  years.  However,  little  has 
been  done  to  resolve  the  problem.  The  assumption  generally  made  was  that 
operational  personnel  would  work  around  the  problem. 

The  belief  that  the  above  was  not  a  responsible  approach  on  the 
part  of  the  SARSAT  system  designers  has  led  to  the  developmental  work 
outlined  in  the  following  discussion.  This  work,  initiated  at  DREO,  is 
presented  in  terms  of  its  objectives,  a  definition  of  LUT  data  quantifiers, 
and  the  LUT  to  CMCC  data  transfer  flow.  Specific  attention  is  given  to  a 
LUT  cluster  analysis  process  and  a  CMCC  pass-to-pass  merge  algorithm. 


3.1  Objective 


The  objectives  of  the  studies  discussed  herein  are  to  demonstrate 

that: 

•  SARSAT  users  can  be  better  served  and  hence  can  react  more 
appropriately  if  they  are  given  more  information  about  the 
alert  data  being  generated  by  the  system; 

•  Simple  but  highly  effective  alert  data  descriptors  are  either 
available  from  the  current  LUT  data  base,  or,  can  be  generated 
quite  easily; 

•  The  CMCC  requires  a  pass-to-pass  merge  algorithm  to  update 
incoming  data  from  the  LUT,  and,  such  an  algorithm  is  easy  to 
develop. 


3.2  Data  Quantifiers 


For  each  SARSAT  alert  at  121.5/243  MHz,  the  Canadian  LUT 
generates  a  record  in  the  WLSDAT  file.  This  file  contains  the  beacon 
location  information  and  associated  data  which  was  obtained  as  a  result  of 
the  estimation  process.  The  current  definition  of  this  file  is  as  given  in 
Table  1. 


Word 

Description 

1 

satellite  identifier 

2 

orbit  revolution  number 

3 

orbit  determination  and  prediction 

4-6 

time  of  acquisition  of  signal  (seconds  from  1980) 

7-9 

time  of  loss  of  signal  (seconds  from  1980) 

10-142 

not  used  (zero) 

Table  1(a):  WLSDAT  Record  Formats  (Header  Record) 
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Word 

Type 

Description 

1 

I 

If  406  MHz,  ELT  identifier  (60  bits),  if  121.5/243.0  MHz, 

4  ASCII  blanks  and  real  correlation  score. 

5 

I 

Data  type  used  to  generate  solution  (see  Table  1(c)) 

6-8 

D 

Time  ELT  position  was  calculated  (seconds  from  1980) 

9-10 

R 

Initial  estimate  of  cross-track  angle  (deg) 

11-12 

R 

Initial  estimate  of  time  of  closest  approach 
(seconds  from  TAOS) 

13-14 

R 

Initial  estimate  of  frequency  bias  (Hz) 

15-78 

- 

More  probable  solution  (see  Table  1(d)) 

79-142 

- 

Less  probable  solution  (see  Table  1(d)) 

Table  1(b):  WLSDAT  Record  Formats  (Data  Record) 


Bit  Set 

Data  Type 

0 

DAT406:  406  MHz  "Bent  Pipe"  data 

1 

DAT406:  2.4  Kb/s  real  time  data 

2 

DAT406:  2.4  Kb/s  COSPAS  stored  data 

3 

CBC121 

4 

CBC243 

5 

I AVI 2 1 

6 

IAV243 

7 

SST121 

8 

SST243 

Table  1(c):  WLSDAT  Record  Formats  (Data  Type  (word  5)). 


Word* 

Type 

Name 

Description 

15-16 

R 

ALAT 

ELT  latitude  (deg  N) 

17-18 

R 

ALONG 

ELT  longitude  (deg  W) 

19-20 

R 

ALT 

ELT  altitude  (meters) 

21-22 

R 

CTA 

Cross-track  angle  (deg) 

23-24 

R 

TCA 

Time  of  closest  approach  (seconds  from  TAOS) 

25-26 

R 

BIAS 

ELT  frequency  bias  (Hz) 

27-28 

R 

ELT  frequency  drift  (Hz/mi n) 

29 

I 

NPTS 

Number  of  frequency  measurements 

30 

I 

NITER 

Number  of  WLS  iterations 

31-32 

R 

AMEAN 

Average  of  data  residuals  (Hz) 

33-34 

R 

SDEV 

Standard  deviation  of  data  residuals  (Hz) 

35-36 

R 

TREND 

Trend  factor  of  data  residuals  (Hz) 

37-44 

R 

VARY 

Standard  deviation  of  CTA,  TCA,  BIAS,  DRIFT 

45-56 

R 

CORR 

Correlation  coefficients 

57-58 

R 

TIMSTA 

Time  to  first  frequency  measurement 
(seconds  from  TAOS) 

59-60 

R 

TIMEND 

Time  to  last  frequency  measurement 
(seconds  from  TAOS) 

61-62 

R 

PROB 

Probability  of  true  solution 
(and  not  ambiguous  one) 

63-64 

R 

VLAT 

Standard  deviation  of  latitude  (deg) 

65-66 

R 

VLONG 

Standard  deviation  of  longitude  (deg) 

67-68 

R 

CLALO 

Correlation  coefficient  between  latitude  and 
longitude  (normalized) 

69-70 

R 

MAJOR 

Major  axis  of  error  ellipse  (km) 

71-72 

R 

MINOR 

Minor  axis  of  error  ellipse  (km) 

73-74 

R 

HEAD 

Heading  angle  of  error  ellipse  (deg) 

75 

I 

EXPECT 

Expected  circular  error  (km) 

76 

I 

SEACH 

Expected  search  area  (km2) 

77 

I 

QUAL 

Quality  factor  for  CBC  data  (sum  amplitudes) 

78 

I 

MESS 

Flag  indicating  whether  the  ELT  data  was  sent 
via  an  alert  message  (0=no,  l=yes) 

*  For  less  probable  solution,  add  64  to  word  number. 

Table  1(d):  WLSDAT  Record  Formats  (Solution  Data). 


Drawing  from  data  available  from  the  WLSDAT  file,  parameters 
associated  with  the  location  estimate  are  defined  under  the  following 
headi ngs : 

•  Quality 

•  Geometry 

•  Frequency 

•  Ambiguity 

•  Merge 


-  8  - 


In  order  to  emphasize  a  range  of  uses  of  these  data,  output  from 
the  DREO  development  activity  is  categorized  as  being  either  primary  or 
secondary  data.  Primary  data  has  direct  operational  use  while  the 
secondary  data  is  needed  for  internal  CMCC  operations  and  more  detailed 
technical  support.  A  sample  output  from  a  DREO  LUT  emulation  process  's 
illustrated  in  Figure  3.  This  process  will  be  discussed  in  subsequent 
sections.  Prior  to  that  discussion,  the  definitions  of  the  data 
quantifiers  illustrated  are  given. 


3.2.1  Quality  Parameters 


Primary  quality  parameters  requiring  definition  include: 

•  CAT 

•  Q 

•  CL  SIZE 

•  SIG  TYPE 


CAT  -  Quality  Category 


A  number  of  different  approaches  have  been  suggested  to 
categorize  the  quality  of  the  alert  data.  On  the  basis  of  simplest  is 
best,  the  current  favoured  approach  is  the  following: 


CAT  Definition 

A  0  $  STD  4  8 

B  8  <  STD  ^  18 

C  18  <  STD  c  40 

D  STD  >  40 


The  category  of  the  signal  is  based  solely  on  the  standard 
deviation  of  data  residuals  (Hz),  i.e.  SDEV  found  in  the  WLSDAT  file. 


Q  -  Quality  Factor 


Q  is  intended  to  be  a  measure  of  the  density  of  the  Doppler  curve 
taking  into  account  geometry  effects.  It  is  a  measure  of  the  amount  of 
data  in  the  curve  relative  to  an  ideal  curve.  It  therefore  ranges  in  value 
from  0. 0-1.0,  one  being  equated  as  perfect  in  terms  of  data  density  (but 
not  necessarily  trend). 

The  ideal  curve  is  defined  to  be  one  which  consists  of  450  points 
or  spans  a  time  of  15  minutes.  Therefore 

N0  =  450 
T Q  =  15  minutes 
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FIGURE  7:  LUT/CMCC  Emulation 
Processing  Flow 
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As  background  to  the  presentation  of  the  results  of  the  LUT  to 
CMCC  emulation,  the  method  of  approach  is  described.  An  overview  of  the 
results  from  the  sample  period  is  then  presented.  The  impact  of  both  the 
cluster  and  merge  processes  are  discussed,  and  the  utility  of  the 
previously  described  location  data  qualifiers  are  demonstrated.  Finally,  a 
number  of  case  studies,  related  to  the  Kalman  Filter  process,  which 
'llustrate  the  effect  of  multiple  detections  are  presented. 


4.1  Method  of  Approach 


As  part  of  the  SARSAT  D&E  activity,  the  SARSAT  Project  Office 
developed  the  SARSAT  Evaluation  Facility  (SEF).  In  effect,  this 
constituted  a  structured  computerized  data  base  of  LUT,  CMCC  and  SAR 
evaluation  data.  Data  from  the  LUT  and  CMCC  for  the  period  1  Jan  83  to 
1  Oct  34  were  routinely  stored  on  magnetic  tape,  transferred  to  the  SEF  and 
incorporated  into  the  data  base.  Operational  search  and  rescue  data  are 
available  in  paper  format  and  can  be  manually  integrated  with  the  SARSAT 
evaluation  data.  Therefore,  online  access  is  available  for  any  sample 
period  ’in  the  aforementioned  time  range. 

In  order  to  test  the  LUT  to  CMCC  data  flow  as  described  in 
Section  3  and  illustrated  in  Figure  4,  the  approach  adopted  was  to  build  a 
LUT/CMCC  emulator.  The  input  to  the  emulator  would  be  historical  LUT  data. 
The  advantage  of  this  approach  is  that  in  the  first  instance,  it 
characterizes  the  SARSAT  environment,  particularly  at  the  LUT,  but  also,  it 
offers  the  opportunity  to  assess  the  impact  of  the  output  from  the  LUT  to 
the  CMCC  when  different  filters  are  applied  to  the  data. 

Considerable  software  development  was  required  to  produce  the 
LUT/CMCC  emulation  illustrated  in  Figure  4.  The  general  approach  was  that 
as  illustrated  in  Figure  7.  It  is  not  the  intention  to  document  herein  the 
developed  analytical  tools  used  to  support  the  study  results,  but  rather  to 
overview  the  approach.  The  developed  software  are  documented  elsewhere. 

Therefore,  referring  to  Figure  7,  the  general  data  retrieval  flow 
was  as  follows.  Using  the  SEF  data  base,  previously  described,  a  program 
called  DENSY  was  developed  to  access  LUT  data.  This  program  allows 
retrieval  of  data  according  to  a  number  of  criteria,  for  example,  a  date 
range,  satellite  used,  beacon  transmission  frequency,  etc.  Essentially, 
the  DENSY  program  accesses  the  WLSDAT  files  described  in  Table  1  and 
produces  a  set  of  data  files  which  are  used  to  "drive"  the  simulation. 
These  data  can  be  viewed  as  the  WLSDAT  data  retrieved  in  accordance  with 
the  selected  DENSY  input  criteria.  The  resulting  data  is  referred  to  as 
the  LUT  Emulator  data  base. 

At  this  stage  of  the  process  flow,  the  objective  was  to  simulate 
the  LUT  handling  the  WLSDAT  data  in  a  manner  illustrated  in  Figure  4.  A 
cluster  analysis  was  carried  out  on  the  data  and  the  previously  described 
data  quality  parameters  calculated.  A  cluster  representati ve  was  selected 
and  output  files  produced  to  simulate  transmission  of  data  from  the  LUT  to 
the  CMCC.  The  result  is  the  CMCC  Emulator  data  base  formed  by  the  program 
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These  are  the  parameter  data  for  each  location  for  the  real  and  image 
solutions,  but  also,  a  linked  list  of  case  numbers  derived  as  a  result  of 
the  merge  process.  For  example.  Case  15  in  Figure  6  has  a  MERGE  NO  of  two. 
This  means  that  two  cases  are  associated  with  this  location,  i.e..  Case  15 
and  although  not  explicitly  illustrated.  Case  3.  The  entries  in  Case  15, 
LUT  real  solution,  are  the  output  of  the  Kalman  Filter,  not  the  results 
from  the  LUT  pass  2  processing.  The  image  data  in  the  Case  15  data  entry 
are  the  LUT  parameters  which  necessarily  are  not  used  in  any  future 
processing. 

Lastly,  the  AMBG  FLAG  traces  the  current  estimate  identifying 
which  solution  is  the  true  solution,  zero  implies  the  true  solution  and  1 
implies  the  image  solution.  Since  in  many  cases  the  LUT  cannot  distinguish 
between  the  real  and  ambiguous  location,  this  flag  is  redefined  when  image 
data  is  successfully  matched  against  previous  cases.  In  this  way,  the  LUT 
input  data  ordering  is  maintained  while  at  the  same  time,  case  ambiguity 
resolution  is  identified. 

The  PASS,  CASE,  MERGE  and  DATA  files  as  described  are  really 
internal  files  designed  to  allow  user  access  to  the  data  in  accordance  with 
his  needs.  A  couple  of  such  access  examples  are  illustrated.  The  user  may 
require  the  output  of  all  active  cases.  The  CASE  file  is  interrogated, 
starting  from  the  oldest  active  file,  and  the  case  status  is  read.  The 
status  flag  is  interpreted  to  distinguish  between  active  single  detections 
and  merged  cases  (ambiguity  resolved).  The  MERGE  file  data  provides  the 
current  estimate  of  the  transmission  location  while  the  DATA  file  provides 
the  ancillary  confidence  data.  Regional  distribution  of  the  data  can  be 
effected  by  checking  the  Region  indicator  (it  is  presumed  that  the  CMCC 
carried  out  the  region  calculation  upon  receipt  of  the  cluster  data  and 
entered  the  region  indictor  into  the  primary  set  before  concatenating  the 
cluster  data  to  the  DATA  file).  The  user  may  want  to  manually  review  all 
single  detections  with  good  quality  indicators.  The  rationale  here  is  that 
merged  events  are  able  to  be  handed  off  for  immediate  SAR  action  while  low 
quality  single  detections  may  not  contain  sufficient  information  for  any 
actioning.  Therefore  it  may  be  useful  to  review  the  good  single  detections 
and  try  and  correlate  these  data  against  obvious  signal  location  sources, 
i.e.  populated  areas,  airports,  etc. 

As  is  evident,  and  as  will  be  discussed  in  the  next  section,  the 
files  can  support  numerous  statistical  reporting  processes  which  would  help 
the  CMCC  personnel  monitor  their  throughput. 


4.0  ANALYTICAL  TOOLS  DEVELOPED/ 
VALIDATION  OF  APPROACH 


The  suggested  approach  as  outlined  has  been  studied  in  some 
detail.  This  was  accomplished  by  selecting  a  sample  period  in  time, 
retrieving  historical  LUT  data  for  this  period,  mechanizing  the  approach 
previously  discussed  and  analyzing  the  impact  of  the  LUT  to  CMCC  data 
f  1  ow. 
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will  support  retrieval  of  case  data  based  on  time,  satellite  type,  source 
and/or  satellite  orbit  number. 

The  CASE  file  consists  of  one  entry  for  each  cluster  derived  by 
the  detecting  LUT.  Its  primary  purpose  is  to  control  the  merging  and  aging 
process  of  the  CMCC  data.  For  this  purpose,  case  time,  status  and  case 
type  are  logged  into  the  file.  Time  is  carried  in  the  rather  arbitrary 
form  of  number  of  days  since  1950.  The  exact  basis  of  the  time  scale  is 
not  important  since  it  is  only  used  to  measure  the  relative  passage  of 
time.  The  case  and  pass  numbers  provide  pointers  to  the  DATA  and  PASS 
files.  The  status  flag  is  important  to  the  merge  process.  It  identifies 
the  case  status  through  the  assignment  of  the  following  indicators: 

Status  Assignment  Meaning 

-1  Single  Detection,  Case  Aged  Out 

0  Single  Detection,  Case  Active 

1  Merged  Case,  Data  Superceded 

2  Merged  Case,  Case  Active 

3  Merged  Case,  Case  Aged  Out 

The  type  flag  indicates  the  number  of  merges  that  have  occurred  on  the  case 
data  up  to  and  including  the  time  of  processing  of  the  case. 

The  CASE  file  is  intentionally  defined  to  be  small  in  terms  of 
record  length  since  it  is  continually  accessed  during  the  merge  process. 
When  data  are  received  at  the  CMCC,  it  is  suggested  that  the  CASE  file  be 

interrogated  to  find  the  oldest  active  case,  i.e.  the  status  flag  is  used 

for  this  purpose.  At  the  same  time,  the  case  time  is  compared  to  the 

incoming  pass  time  and  if  it  exceeds  the  "aging"  criteria,  the  case  is  aged 

out  of  the  system  by  a  suitable  redefinition  of  the  status  flag.  At  this 
stage  all  acti ve  cases  (those  with  Status  =  0  or  2)  are  compared  to  the 
incoming  pass  data,  and  if  a  comparison  is  successful,  the  case  status 

reverts  to,  Merged  Case,  Data  Superceded  (Status  flag  =  1)  and  a  MERGE  file 

entry  is  recorded.  If  a  case  from  the  current  pass  does  not  merge  with 

previous  pass  data,  then  it  is  entered  into  the  MERGE  file  as  a  single 

detection,  case  active  (Status  flag  =  0  in  the  CASE  file). 

Figure  6  illustrates  output  from  a  MERGE  file.  It  contains  the 
case  and  pass  numbers  for  access  back  to  the  CASE  and  PASS  files  and  as 
required,  direct  access  to  the  source  data  in  the  DATA  file.  The  location 
and  frequency  bias  data  are  also  logged  into  this  file.  If  the  case  is  a 
single  detection  (either  active  or  aged)  then  the  location  and  bias 
estimates  are  the  data  as  provided  by  the  LUT.  If,  however,  a  comparison 
was  successful,  i.e.  a  merge  took  place,  then  the  location  and  bias  data  in 
the  MERGE  file  are  the  output  results  of  the  Kalman  Filter  calculation 
described  in  Section  3.3.5.  Therefore,  the  entry  in  the  MERGE  file  for  a 
particular  case  is  the  system's  best  estimate  of  the  location  and 
associated  parameters  of  the  transmission.  The  source  data  for  the 
particular  pass  is  retained  in  the  DATA  file.  The  VLAT,  VLONG,  R  and  VBIAS 
Darameters  are  the  input  to  the  Kalman  Filter. 

The  MERGE  NO  is  the  size  of  the  merge  list  (not  illustrated  in 
Figure  6).  The  MERGE  file  has  four  records  associated  with  each  case. 
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FIGURE  5:  Sample  PASS  and  CASE  Files 


distance  criteria  is  to  identify  clusters  or  groupings  of  locations  which 
tend  to  indicate  the  detection  of  an  ELT/EPIRB  and  its  associated  side¬ 
bands.  In  the  absence  of  a  specific  ELT/EPIRB  identifier,  the  estimated 
bias  of  the  beacon  is  used  to  distinguish  two  different  transmissions  in 
the  same  region. 

The  algorithm  to  develop  the  clusters  is  quite  straightforward  in 
its  mechanization.  In  its  simplest  terms  it  is  a  triangulated  compare 
process  with  a  'knock  out'  activity  when  the  comparison  is  successful.  The 
general  flow  is  as  follows.  The  pair  of  locations  for  the  first  detection 
are  compared  to  all  the  other  detections,  and  when  comparisons  are 
positive,  the  latter  events  are  removed  from  the  system.  The  cluster 
process  then  continues  until  all  groupings  are  identified.  The  end  result 
is  a  re-ordered  WLSOAT  file  for  the  particular  pass. 

During  the  cluster  analysis,  the  parameters  Q,  PROBT,  ELEY,  and 
ABS  are  calculated  as  discussed  in  Section  3.2.  The  CL  SIZE  and  FREQ  FLAG 
are  established  as  part  of  the  process.  Finally,  the  SIG  TYPE,  CTA  and  TCA 
flags  are  set  in  accordance  with  the  criteria  previously  discussed.  The 
output  from  the  cluster  analysis  is  the  CLUSTER  file,  as  noted  in  Figure 
4. 

The  final  step  in  the  cluster  analysis  is  the  selection  of  a 
representative  element  from  each  cluster.  The  criteria  which  was  used,  for 
this  selection  was  to  pick  the  first  element  in  the  cluster.  The  LUT,  in 
its  Doppler  processing,  extracts  the  Doppler  curves  in  order  of  signal 
strength.  Therefore,  the  first  element  in  the  cluster  is  the  best  estimate 
because  it  was  the  strongest  signal.  Other  selection  criteria  or 
approaches  are  possible. 

Figure  3  illustrates  a  sample  pass  resulting  from  the  cluster 
analysis.  The  parameters  given  in  Figure  3  are  those  suggested  to  be 
transferred  from  the  LUT  to  the  CMCC. 


3.5  CMCC  MERGE  Process 

The  CMCC,  upon  receipt  of  the  data  from  the  LUT  (or  conceivably 
any  other  source  that  can  support  the  parameter  definition),  appends 
pertinent  data  to  a  PASS  file,  CASE  file  and  the  main  DATA  file  Sample 
structures  for  the  PASS  and  CASE  files  are  illustrated  in  Figure  5.  The 
DATA  file  is  simply  a  concatenation  of  CLUSTER  files. 

The  PASS  file  has  the  dual  function  of  being  a  pointer  file  and  a 
historical  statistical  reference  file.  Upon  receipt  of  the  cluster  data, 
the  PASS  file  is  updated  with  the  basic  pertinent  data  related  to  the  pass. 
A  CMCC  pass  number  is  assigned,  the  pass  time,  satellite  used  and  source  of 
the  data  are  recorded.  Basic  LUT  statistics  are  also  noted,  i.e.  the 
number  of  LUT  detections  and  the  number  of  derived  clusters.  The  latter  is 
a  measure  of  data  compression  as  a  result  of  the  cluster  analysis.  Each 
cluster  is  now  considered  as  a  CMCC  case,  analogous  to  the  currently 
defined  CMCC  reference  number.  The  range  of  case  numbers  assigned  as  a 
result  of  the  pass  are  logged  in  the  PASS  file.  Therefore,  the  PASS  file 


•  The  LUT,  a  signal  processor,  has  only  a  minimal  role  as  a 
collator  of  information; 

•  The  LUT  process  is  a  real  time  activity,  it  carries  no  history 
with  it; 

•  The  CMCC  has  visibility  into  the  total  SARSAT  environment  both 
nationally  and  internationally; 

•  The  CMCC  carries  history  and  the  age  when  alert  data  from  the 
LUT  is  considered  inactive  is  under  the  control  of  the  CMCC 
operator. 

Figure  4  summarizes  the  suggested  LUT  to  CMCC  data  flow  process. 
The  process  begins  with  the  production  of  the  WLSDAT  file,  see  Table  1,  one 
record  is  created  for  each  ELT/EPIRB  detected  by  the  LUT.  The  WLSDAT  data 
is  subjected  to  a  cluster  analysis  in  which  data  is  grouped  and  ordered 
according  to  a  distance  and  beacon  bias  check  criteria.  This  process  is 
discussed  in  more  detail  in  the  next  section.  The  result  of  this  process 
is  the  cluster  file.  A  representative  from  each  of  the  developed  clusters 
is  then  selected  for  transmission  to  the  CMCC. 

The  CMCC,  upon  receipt  of  the  cluster  data  from  the  LUT, 
initiates  a  number  of  actions.  Firstly,  a  PASS  file  containing  pertinent 
historical  information  related  to  satellite  passes  processed  is  updated. 
This  file  contains  such  information  as  a  pass  number  (similar  to  the  CMCC 
reference  numbers  or  case  number),  time  of  pass,  date,  SATPAS  and  AOS/LOS, 
number  of  clusters  in  the  pass,  etc.  A  CASE  file  is  also  updated  to 
contain  a  case  number  (currently  called  the  CMCC  reference  number),  the 
above  mentioned  pass  number,  and  status  of  the  case.  The  MERGE  file 
besides  containing  the  case  and  pass  numbers,  has  the  beacon  location  data, 
merge  update  data  and  most  importantly,  the  merge  list.  The  merge  list  is 
a  backward  looking  linked  list  identifying  all  previous  detections 
associated  with  the  current  active  case.  The  creation  of  the  MERGE  file 
through  a  merge  process  is  discussed  in  Section  3.5.  Finally,  the  master 
data  file,  containing  all  the  cluster  data  incoming  from  the  LUT  is 
updated. 

Through  simple  linkage  between  the  MERGE,  CASE,  PASS  and  DATA 
files,  the  pertinent  summarization  of  the  data  can  be  presented  to  the  CMCC 
operator  for  his  review  and  onward  transmission  to  the  RCC  controllers  for 
their  action. 

The  next  two  sections  consider  in  more  detail  the  cluster 
analysis,  suggested  to  be  carried  out  at  the  LUT,  and  the  merge  process, 
intended  to  be  performed  at  the  CMCC. 


3.4  The  LUT  Cluster  Process 

As  illustrated  in  Figure  4,  the  LUT  cluster  process  involves  a 
total  review  of  the  WLSDAT  file  for  a  given  pass  (121.5  MHz  data,  and  243 
MHz  data  if  available),  and  grouping  these  LUT  generated  detections  based 
upon  a  distance  and  the  beacon  frequency  bias.  The  intention  of  the 


where 


an  =  latitude 


V*  =  Variance  in  the  latitude  estimate. 
an 


\n  =  longitude  -  Variance  in  the  longitude  estimate. 

p  =  correlation  between  latitude  and 
longitude  in  the  estimation. 

A  number  measurement  is  made  resulting  in  an  updated  vector  X  and 
associated  covariance  matrix  C. 

In  order  to  update  the  state  vector  Xn,  the  Kalman  gain  vector  is 
calculated  by: 


K  =  C  (C  +  C  ) 
n  n 


Xn+i  =  Xn  +  K(Xn  -  X)  and  Cn+1  =  (I-K)Cn 


In  an  analogous  manner,  BIAS  can  be  updated  using  the  variance  on 
the  BIAS  as  provided  in  the  WLSDAT  file 


Bn.l  '  Bn  <Bn  *  B> 


VV8. 


’"*1  +  V8. 


3.3  LUT  to  CMCC  Data  Transfer  Flow 


Given  the  LUT  to  CMCC  parameter  definition  as  described  in 
Section  3.2,  it  is  now  useful  to  consider  the  flow  of  information  in  a  more 
global  sense.  The  following  discussion  is  premised  on  the  assumption  that 
the  LUT  and  CMCC  functional  activities  should  take  into  account  the 
following: 
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3.2.3  Frequency  Resolution  Parameters 

A  FREQ  Flag  is  included  in  the  primary  data  set  to  note  whether 
as  a  result  of  the  clustering  process,  the  observed  cluster  frequency  is 
121.5  MHz  (Flag=8) ,  243  MHz  (Flag=16)  or  Dual  frequency  121.5/243  MHz 
(Flag=24) . 


Due  to  operational  requirements,  the  estimated  absolute  frequency 
of  the  beacon  is  provided  in  the  secondary  data,  i.e. 

ABS  =  121.5  +  (HM  -  12.5)  *  1000 
1000 

The  estimate  of  BIAS,  as  taken  from  the  WLSDAT  file  is  given,  and  a  space 
is  provided  for  the  estimated  SWEEP  rate.  The  latter  is  provided  as  a 
reserve  field  should  future  LUT  developers  elect  to  have  this  parameter 
incorporated  into  new  LUTs. 


3.2.4  Ambiguity  Resolution  Parameters 

PROBS  is  the  probability  of  ambiguity  resolution  using  the 
standard  deviation,  and  is  available  from  the  WLSDAT  file.  PROBT  is  the 
probability  of  ambiguity  resolution  using  TREND.  The  method  of  calculation 
is  identical  to  that  of  PROBS  except  TREND  is  substituted  for  SDEV. 


3.2.5  Merge  Parameters 

It  is  not  logical  to  perform  intra  pass  merging  at  a  LUT 
especially  in  a  multi  LUT  environment.  It  is  logical  to  merge  data  between 
passes  at  the  CMCC.  In  order  to  do  this,  the  following  parameters  are 
included  in  the  secondary  data  to  support  merge  operations: 

VLAT  =  standard  deviation  of  the  latitude  estimate; 

VLONG  =  standard  deviation  of  the  longitude  estimate; 

CLALO  =  correlation  between  latitude  and  longitude; 

VBIAS  =  standard  deviation  of  the  BIAS. 

The  algorithm  to  update  the  location  estimate  is  that  provided  in 
the  LUT,  see  SM-LUT-284/1,  page  3-2.  It  is  a  simple  Kalman  Filter 
technique  and  is  summarized  as  follows. 

At  a  given  period  in  time  there  exists  a  state  vector  X_  of 
latitude  and  longitude  and  an  associated  covariance  matrix  Cn  which  define 
the  state  just  prior  to  the  arrival  of  new  information.  Xn  and  Cn  are  of 
the  form 


X  = 

an 

C  = 

r  v. 

-F 

n 

n 

p/  V*  V, 

L  '  an  Ni 

\  . 

CL  SIZE 


CL  SIZE  is  the  numerical  cluster  size  derived  at  the  LUT  by 
merging  sidebands  according  to  distance  and  bias  criteria.  In  the  case  of 
dual  frequency  transmission,  CL  SIZE  would  reflect  the  merging  by  frequency 
as  well . 


SIG  TYPE 


SIG  TYPE  is  a  flag  to  annotate  the  type  of  signal  observed.  Its 
definition  is  based  on  the  premise  that  a  cluster  of  size  one  is  suspect,  a 
cluster  in  the  range  2-5  is  probably  a  good  ELT/EPIRB  signal  with  noted 
sidebands  while  a  cluster  that  is  greater  than  5  tends  to  imply  an 
interfering  signal  source. 

Therefore  SIG  TYPE  is  defined  as  follows: 

U  CL  SIZE  =  1 

E  1  <  CL  SIZE  <  5 

I  CL  SIZE  >  5 

The  secondary  data  set  related  to  Quality  is:  STD,  TREND,  PTS, 
NMWLS.  The  first  three  parameters  are  standard  deviation,  trend  and  no.  of 
data  points,  given  in  their  quantitative  terms  as  available  from  the  WLSDAT 
file,  i.e.  SDEV,  TREND,  NPTS.  The  NMWLS  is  the  number  of  least  squares 
iterations  carried  out  (NITER  in  the  WLSDAT  file)  and  is  a  qualitative 
indication  of  the  degree  of  difficulty  encountered  in  deriving  a  solution. 
A  value  of  NMWLS  =  -5  signals  nonconvergence  of  the  curve  fitting  process. 


3.2.2  Geometry  Parameters 

At  the  primary  level  two  flags,  one  related  to  the  estimated 
cross  track  angle,  CTA,  and  the  other,  time  of  closest  approach,  TCA,  are 
provided.  The  flags  are  defined  as  follows: 


Flag  Value  Definition 


CTA 


-1  0  <  CTA  <  2 

0  2  « CTA  *  18 

1  CTA  > 18 


TCA 


0  unless 

1  TCA<(AOS-TCACUT)  or  TCA>(LOS+TCACUT) 


where  TCACUT  is  currently  defined  to  be  one  minute. 

The  secondary  level  geometry  parameters  include  the  actual  values 
for  CTA  and  TCA  plus  an  estimate  of  the  ELT  elevation  angle. 


N  =  no.  of  data  H,*nts,  NPTS  in  the  WLSDAT  file,  and  CF  is  defined  as 
follows: 


Tn 

If  TCA  +  —  <  LOS 
2 

and  TCA  -  —  >  AOS 
2 

Tn 

If  TCA  +  —  <  LOS 
2 

and  TCA  -  —  <  AOS 
2 

If  TCA  +  I®  >  LOS 
2 

Tn 

and  TCA - S  >  AOS 

2 

If  TCA  +  —  >  LOS 
2 

Tq 

and  TCA - S  <  AOS 

2 


then  CF  =  1 


then  CF  =  - ~ - 

-S  +  [TCA -AOS] 
2 


then  CF  =  - ± - 

Is  +  [LOS-TCA] 
2 


then  CF  = 


Tq 

LOS-AOS 


TCA,  LOS  and  AOS  are  the  standard  definitions  and  are  available  in  the 
WLSDAT  file. 
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FIGURE  3:  Sample  Pass  -  Suggested 
LUT  to  CMCC  Transfer  File 
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DMERG.  It  should  be  noted  that  control  is  based  upon  satellite  pass.  This 
reflects  the  assumption  that  the  LUT,  as  a  facility,  carried  no  history 
with  it. 

The  CMCC  Emulator  data  base  can  be  viewed  as  a  concatenated  set 
of  LUT  data  for  which  no  pass-to-pass  associations  have  been  established. 
Using  the  program  LTMER,  these  associations  are  developed.  Starting  at  the 
beginning  of  the  data  files,  LUT  detections  are  compared  on  a  pass-to-pass 
basis  to  establish  multiple  detections,  the  data  is  merged  where 
appropriate  and  new  location  estimates  are  calculated.  The  merging  process 
imposes  a  time  window  on  the  data  and  therefore  allows  detections  to  be 
aged  out  of  the  system,  superceded  by  new  detections,  or  remain  active  as 
the  time  window  reaches  the  boundary  of  the  test  period. 

The  output  from  the  merge  process  is  data  which  is  in  a  form 
available  for  operational  actioning.  It  also  provides  the  statistical 
basis  upon  which  one  can  assess  the  impact  of  the  whole  cluster/merge 
process.  These  data  are  accessed  by  a  program  called  MDUMP,  the  output 
from  which  is  discussed  in  the  following  sections. 

As  a  final  footnote  to  this  discussion  on  the  method  of  approach, 
it  should  be  noted  that  the  data  retrieval  process  illustrated  in  Figure  7 
is  a  sequential  process  and  not  a  real  time  handling  of  data  as  would  be 
the  case  in  the  "real  world".  For  the  purposes  of  the  studies  in  question, 
it  would  have  been  too  time  consuming  to  produce  a  real  time  simulation. 


4.2  Test  Period  Selection 

In  order  to  run  the  LUT /CMCC  emulation,  a  test  period  from  which 
to  retrieve  historical  data  had  to  be  selected.  In  a  purely  arbitrary 
fashion,  the  month  of  September  1984  was  chosen.  These  data  just  happened 
to  be  conveniently  available.  Attempts  were  made  to  generate  a  data  base 
for  the  full  month  but  system  difficulties  were  encountered  because  of  file 
size  problems.  Rather  than  take  the  time  to  solve  the  computer  system 
problems,  the  data  base  generated  consisted  of  the  first  ten  days  of 
September,  1984,  instead  of  the  whole  month.  In  reality,  it  is  irrelevant 
which  time  period  is  chosen  and  how  long  the  sample  period  is,  as  long  as 
sufficient  data  are  processed  to  produce  stable  statistics.  In  retrospect, 
the  ten  day  period  selected  meet  these  requi rements. 

The  results  of  the  LUT/CMCC  data  flow  emulation  are  summarized 
for  the  ten  day  period  in  question  and  then  the  impact  of  the  cluster  and 
merge  processes  are  characterized. 


4.3  Test  Period  Results  -  Overview 


During  the  period  1-10  September  1984,  the  SARSAT  facilities  had 
access  to  the  three  operational  COSPAS  satellites.  The  summary  of  the 
cl uster/merge  process  and  the  control  parameters  input  to  the  emulation  are 
given  in  Table  2  below. 
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TABLE  2 

Cluster  Merge  Summary 


Start  Date:  840901 
End  Date:  840910 


Summary 


No.  Passes  Processed:  139 

No.  LUT  Detections:  1222 

No.  Clusters  Identified:  851 

Input  Parameters 

Case  Decay  Time  (hrs):  24.00 

Distance  Criteria  (km):  250.00 

Bias  Range  (Hz):  3000.00 


During  the  sample  period,  the  Ottawa  LUT  tracked  139  satellite 
passes  or  about  14  passes  a  day  and  produced  1222  ELT/EPIRB  detections, 
while  there  is  considerable  diurnal  variation,  this  equates  to 
approximately  9  detections  per  pass.  Out  of  these  1222  LUT  detections,  the 
previously  described  cluster  process  identified  851  clusters.  The  input 
criteria  for  the  cluster  process  were  as  given  in  Table  2.  For  the  merge 
process,  a  case  decay  time  of  24  hours  was  selected.  In  other  words,  if  a 
particular  detected  location  was  inactive  for  more  than  24  hours,  i.e. 
subsequent  passes  did  not  verify  transmission,  that  location  was  aged  out 
of  the  merge  process. 

Figure  8  summarizes  the  results  of  the  cluster  merge  process  for 
the  10  day  period  and  the  pertinent  data  are  given  in  Table  3.  Clearly,  a 
number  of  generalizations  can  be  made  from  these  data. 

Without  totally  justifying  the  comment  at  this  time,  the 
conclusion  is  drawn  that  the  LUT  generated  data  is  very  good.  However,  the 
end  user,  because  of  his  lack  of  visibility  into  the  details  of  these  data, 
cannot  distinguish  better  quality  data  from  poorer  quality  data.  The  user 
is  inundated  with  volumes  of  data  which  must  all  be  treated  in  a  like 
manner.  Therefore,  where  possible,  the  volume  must  be  reduced  and  then, 
the  remaining  data  must  be  categorized. 

In  Figure  8,  it  is  evident  that  30*  of  the  LUT  generated  beacon 
detection  data  can  be  suppressed  at  the  LUT  through  the  cluster  process. 
These  are  the  sideband  data  which  in  themselves  are  of  no  use  to  the  user. 
Of  the  remaining  70%,  51%  are  classified  as  "U"  Type  transmission,  i.e. 
single  element  clusters,  18%,  in  the  absence  of  additional  external 
information  can  be  classified  as  ELT/EPIRB  transmissions,  i.e.  clusters  of 
size  2-5,  and  1%  are  defined  to  be  interferers.  Therefore,  based  on 
cluster  size  alone  and  not  taking  into  account  the  data  quality  indicators 


TABLE  3 


Cluster  Merge  Summary 
Sample  Period:  1-10  Sept  84 


No. 

Per  Cent 

Per  Cent 

Detections 

LUT  Detections 

No.  Clusters 

'Ll"  Type  Transmissions 

No.  Aged/Active 

150 

12.3 

17.6 

No.  Merged 

473 

38.7 

55.6 

No.  Superceded 

350 

No.  Aged/Active 

123 

Total 

623 

51.0 

73.2 

"E"  Type  Transmissions 

No.  Aged/Active 

23 

1.9 

2.7 

No.  Merged 

197 

16. 1 

23.1 

No.  Superceded 

149 

No.  Aged/Active 

48 

Total 

220 

18.0 

25.8 

"I"  Type  Transmissions 

No.  Aged/Active 

1 

0.1 

0.2 
r\  o 

No.  Merged 

7 

0.5 

0*0 

No.  Superceded 

5 

No.  Aged/Active 

2 

Total 

8 

0.6 

1.0 

No.  Clusters 

851 

69.6 

No.  LUT  Detections 


1222 


Single  Detection 
24 J  (150  cases) 


Merged 
Aged/Ac tive 
V  -01  (123  cue.)  , 


Superceded  Cases 
56Z  (350  cases) 


'Ll"  Type  Transmissions 


•V  Type 
51Z  (623  cases) 


Cl uSter 

Suppf  ess » on 
30’  (371  cases) 


"E"  Type 
18Z  (220  cases) 


LUT  Data 


Superceded 
Detections 
60.  (499  cases) 


i  "ORPHAN"  Cases 
1(173  cases) 


/SAP  Cases^v 

(171  cases)  X, 

1«X  \  61 


CMCC  Data 


”1"  Type 
IX  (8  case.) 


Superceded  Cases 
68'  ( 149  cases ) 


ISingle  Detection 
l  10-  (23  cases)/ 


Merced  \ 
Aoed/Actiee  \ 
22  cases)' 


’E"  Type  Transmissions 


FIGURE  8:  Cluster/Merge  Summary 


(these  are  discussed  in  subsequent  sections),  it  is  evident  that  19.  of  tnc 
data  generated  by  the  LUT  are  amenable  to  immediate  user  action,  5H  are 
amenable  to  qualified  actioning  and  30%  require  no  action. 

The  “U"  Type  transmissions,  which  accounted  for  5U  of  the  LUT 
generated  data,  constitute  the  grey  area.  Figure  8  illustrates  the  fact 
that  in  25%  of  these  cases,  no  action  is  required.  These  transmissions 
were  never  verified,  they  were  "orphan"  events.  On  the  other  hand,  only 
10%  of  the  "E"  Type  transmissions  turned  out  to  be  "orphan"  events. 
Therefore  there  is  a  limited  risk,  in  terms  of  resource  utilization,  to 
action  "E"  Type  transmissions  immediately,  while  there  is  considerably  more 
risk  (and  correspondingly  there  are  more  than  twice  as  many  cases) 
actioning  "U"  Type  transmissions. 

The  summary  cluster/merge  data  provided  in  Table  3  and  Figure  8 
allows  one  to  convert  the  number  of  SARSAT  detections  into  the  number  of 
search  and  rescue  incidents.  The  definition  for  a  SAR  incident  would  be  a 
verified  SARSAT  detection.  Therefore  of  the  851  clusters  suggested  to  be 
transferred  from  the  LUT  to  the  CMCC,  80%  were  validated  to  constitute  171 
incidents.  The  conversion  factor  to  translate  SARSAT  incidents  into  SAR 
cases  is  one  in  five.  The  SARSAT  "False  Alarm"  rate  is  of  the  order  of  20% 
i.e.,  2  in  5  SARSAT  detections  are  "orphan"  events  not  verified  by  SARSAT, 
and  90%  of  these  "orphan"  events  come  from  single  element  clusters. 

The  justification  for  the  initial  comment  that  the  LUT  generated 
data  is  very  good  is  now  clearly  evident.  80%  of  the  LUT  data  can  be 
validated  and  it  only  remains  to  characterize  the  remaining  20%  to  assess 
its  utility  to  the  user. 


4.4  Cluster/Merge  Distribution 


In  order  to  lay  the  ground  work  for  the  role  of  the  data  quality 
indicators,  to  be  discussed  in  the  next  section,  the  cluster  size 
distributions  derived  for  the  sample  period  and  the  resulting  merge 
distributions  developed  as  a  result  of  the  merge  process  are  illustrated. 


4.4.1  Cluster  Distributions 


Figure  9  illustrates  the  cluster  data  developed  through  the 
cluster  process  in  terms  of  size  of  the  cluster.  The  data  for  the  851 
clusters  are  then  categorized  in  terms  of  whether  a  subsequent  merge  took 
place. 


These  data  amplify  the  comments  made  previously,  i.e.  the  size  of 
the  cluster  can  be  used  as  a  good  indicator  to  determine  the  users  initial 
reaction  to  incoming  data.  Data  classified  as  "E"  Type  transmissions  are 
actionable  data.  However,  it  is  also  evident  that  "U"  Type  transmissions 
cannot  be  ignored.  As  is  illustrated,  56%  of  the  single  element  data  will 


subsequently  be  validated.  It  is  these  that  require  further 

characterization  in  order  to  assess  whether,  througn  the  use  of  additional 
information,  rules  can  be  developed  to  quide  user  actioning. 

In  summary,  "E"  Type  transmissions,  categorized  solely  on  the 
basis  of  cluster  size,  can  be  viewed  as  ELT/EPIRB  transmissions  and  hence 
are  amenable  to  immediate  user  actioning.  While  "I"  Type  transmissions  are 
not  discussed  in  any  detail,  the  implication  or  assumption  made  is  that  due 
to  the  nature  of  the  transmission,  they  are  actionable.  Approaches  for 
handling  "U"  Type  transmissions  require  further  definition. 


4.4.2  Merge  Distribution 


Figure  10  illustrates  the  number  of  merges  derived  from  the  merge 
process  for  the  period  1-10  September  1984.  These  data  are  more  of 
academic  interest  than  they  are  of  use  to  operational  personnel.  Rather, 
these  data  tend  to  characterize  the  beacon  transmission  environment.  It  is 
evident  that  50%  of  the  validated  transmissions,  i.e.  at  least  one  merge, 
are  not  heard  again.  In  other  words,  the  beacon  activation  period  is 
short,  of  the  order  of  1-2  hours.  These  are  probably  the  short  duration 
false  alarm  incidents. 

The  number  of  merges  seen  at  the  CMCC  is  useful  data  for  RCC 
controllers  since  it  defines,  to  some  extent,  the  age  of  the  event  and 
hence  the  likelihood  that  a  true  distress  is  involved. 


4.5  Data  Quantifiers 


Thus  far,  it  has  been  proposed  that  the  evidence  exists  to  allow 
immediate  operational  action  on  "E"  and  "I"  Type  transmissions.  This 
categorization  is  based  on  cluster  size  alone.  However,  as  discussed,  this 
only  constitutes  about  27%  of  the  data  transferred  from  the  LUT  to  the 
CMCC.  The  remaining  73%,  or  the  “U"  transmissions  need  the  support  of 
other  information. 

In  the  following  discussion  attention  will  focus  on  what 
information  can  be  provided  by  the  data  quantifiers  to  help  operational 
personnel  define  the  type  of  action  to  be  taken.  Figure  11(a)  and  (b) 
summarizes  the  distributions  of  the  Category  Indicator,  Q,  and  the  CTA  and 
TCA  flags  by  transmission  type  for  the  851  clusters. 

The  data  in  Figure  11(a)  and  (b)  suggest  the  following  points  of 
interest.  The  Category  Indicator  and  Q  appear  to  be  useful  parameters  to 
support  actioning  "U"  Type  transmissions.  Generally  speaking,  these 
parameters  identify  good  and  poor  quality  data.  This  trend  is  not  evident 
for  the  "E"  and  "I"  Type  transmissions.  However,  in  this  latter  case,  the 
data  quantifiers  are  not  as  important  since  it  has  already  been  concluded 
that  these  are  actionable  incidents.  The  CTA  and  TCA  flags,  as  would  be 
expected,  do  not  provide  any  guidance  concerning  the  actionability  of  the 
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event.  It  should  be  clarified  here  that  the  point  at  issue  is  whether  to 
action  the  detection  or  whether  to  wait  for  additional  information.  Once 
that  decision  has  been  made,  then  the  data  quantifiers  have  another  very 
important  function;  they  provide  the  user  with  an  indication  of  how  good 
the  location  estimate  is. 

A  number  of  different  definitions  were  identified  to  try  and 
categorize  incoming  LUT  data  as  being  good,  mediocre  or  bad.  The  proposed 
definition  is  as  follows: 

Good  Data:  Category  A  or  B  and  Q  >  0.5. 

Bad  Data:  Category  C  or  D  and  Q  <  0.5. 

Mediocre  Data:  Not  good  and  Not  Bad. 

This  definition  was  tested  against  the  sample  period  data  and  the 
results  are  given  in  Table  4  and  illustrated  in  Figure  12.  It  is  evident 
from  these  data  that  the  above  definition  works  quite  well.  The  suggestion 
has  been  made  that  all  "E"  and  "I"  Type  transmissions  are  actionable 
incidents  upon  receipt  from  the  LUT  {the  sample  period  suggests  that  10%  of 
these  incidents  were  "orphan"  incidents).  This  accounts  for  228  detections 
or  27%  of  the  incoming  data.  With  reference  to  the  "U"  Type  transmissions, 
it  is  now  suggested  that  the  data  categorized  as  good  or  mediocre  is 
amenable  to  immediate  action.  This  categorization  accounts  for  308 
detections  or  an  additional  36%  of  the  incoming  data.  The  sample  period 
suggests  that  36  of  these  308  incidents  were  "orphan"  incidents,  i.e.  6%  of 
the  "U"  Type  transmissions.  The  bad  data  for  which  no  immediate  action  can 
be  recommended  consist  of  the  315  "U"  Type  transmissions  with  poor  data 
quantifiers.  These  data  constitute  37%  of  the  incoming  data.  It  is 
evident  from  Table  4  that  50%  of  these  data  can  be  actioned  by  subsequent 
pass  validation,  but  in  the  first  instance  the  quality  of  the  information 
is  not  good  enough  to  justify  immediate  actioning. 

In  summary,  a  method  has  been  outlined  which  allows  CMCC 
controllers  with  some  degree  of  confidence  to  action  63%  of  all  incoming 
SARSAT  data.  Furthermore,  the  approach  is  simple  and  would  appear  to  work 
quite  well  when  validated  against  historical  data.  The  remaining  37%  of 
the  data  does  not  require  CMCC  controller  intervention  until  it  is 
supported  by  subsequent  pass  or  external  information,  e.g.  SAR  input.  In 
volumetric  terms  and  starting  with  the  number  of  LUT  detections,  clearly 
56%  of  the  LUT  data  (371  detections  suppressed  at  the  LUT  through  the 
cluster  process  and  315  detections  suppressed  initially  at  the  CMCC  because 
of  poor  data  quality)  need  not  be  actioned  by  CMCC  controllers.  The  impact 
of  the  above  strategy  is  to  free  up  valuable  CMCC  controller  time  to  action 
the  better  quality  detections  while  at  the  same  time  minimizing  the 
operational  risk  but  maximizing  resource  utilization. 


4.6  Case  Studies 


From  the  previous  discussion  it  is  clear  that  sufficient 
information  is  available  from  within  the  SARSAT  system  facilities  to  allow 
operational  personnel  to  determine  appropriate  actioning  of  SARSAT  data. 


Data  Categorization  Using 
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The  topic  not  discussed  thus  far  is  the  impact  of  the  merge  process,  i.e. 
the  Kalman  Filter,  on  improving  data  quality.  It  is  not  within  the  scope 
of  the  current  discussion  to  analyze  the  full  impact  of  the  merge  process. 
Instead,  a  number  of  examples,  chosen  from  the  sample  period  1-10  Sept  84, 
have  been  selected  to  illustrate  the  effect  of  the  Kalman  Filter. 

Although  the  sample  period,  1-10  Sept  84,  was  quite  short  it  did 
contain  three  transmission  events  which  illustrate  the  impact  of  the  merge 
process.  These  included  a  search  and  rescue  incident,  a  long  duration 
(presumably  false  alarm)  ELT  transmission  from  the  Chicago  area  and, 
presumably  a  test  beacon  transmission  from  the  Goddard  Space  Flight  Centre 
(GSFC)  near  Washington,  D.C.  Because  each  of  the  transmissions  was 
different  in  nature,  they  illustrate  different  aspects  of  the  merge 
process. 


The  SAR  incident  referred  to  above  was  SAR  CF-WIJ  which  occurred 
on  7  September  1984.  It  involved  a  light  plane,  2  people  on  board,  which 
force  landed  on  Lake  Gachet,  Province  of  Quebec,  because  it  was  low  on 
fuel.  Lake  Gachet  is  about  70  nm  NNW  of  Scheffervi  1  le,  Quebec,  a 
relatively  remote  region.  The  pilot  turned  on  his  ELT  to  signal  his 
situation.  The  incident  site  was  estimated  to  be  56 : 05N ,  67:15W. 

SARSAT  was  used  as  an  initial  alert  for  SAR  CF-WIJ  and  locations 
were  derived  from  the  following  satellite  passes:  C2  07311,  C2  07312,  C2 
07313  and  C3  01071.  In  order  to  illustrate  accuracy  improvement  due  to  the 
merge  process,  one  needs  the  actual  incident  site  and  a  number  of 
detections  from  different  satellite  passes.  These  requirements  were  met 
with  SAR  CF-WIJ. 

Figure  13  illustrates  the  effect  of  the  Kalman  Filter  (the  CMCC 
data)  in  estimating  the  location  of  the  incident.  For  comparison,  the  LUT 
location  estimates  are  included  in  Figure  13.  It  is  significant  to  note 
that  by  the  third  detection,  the  error  in  estimation  is  under  10  km  and 
stablizing  quite  well.  By  comparison,  the  LUT  estimates  can  be  of  the 
order  of  30  km  different  to  the  CMCC  estimates  provided  by  the  Kalman 
F i 1  ter. 


The  GSFC  test  beacon  and  the  Chicago  area  transmission  provided 
additional  visibility  into  the  impact  of  filtering  LUT  data  because  of  the 
duration  of  the  transmissions.  The  GSFC  data  spanned  the  period  1 
September  to  3  September,  and  data  from  16  passes  were  merged.  The  Chicago 
area  transmission  was  initially  detected  on  4  September  and  last  seen  on  7 
September.  In  the  latter  case,  data  from  17  passes  were  used.  The  large 
number  of  repeat  detections  afforded  a  good  opportunity  to  illustrate  the 
difference  between  the  source  LUT  data  and  the  Kalman  filtered  CMCC  data. 
The  two  characteristics  chosen  for  illustration  were  the  impact  on  location 
estimation  and  the  trend  in  parameter  estimation. 

The  actual  location  of  the  beacon  was  not  known  for  either  the 
GSFC  or  the  Chicago  area  transmi tters.  Therefore,  the  last  available 
Kalman  Filter  estimate  was  used  as  the  best  approximation  to  the  true 
location  of  the  transmi ssion. 

Based  on  the  above  approach,  error  diagrams  were  developed  for 
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FIGURE  13 


Error  (km)  in  Location  Estimation 
LUT  Versus  CMCC  Data 


the  LUT  data  and  the  CMCC  data  for  each  of  the  transmission  sites.  These 
are  illustrated  in  Figure  14.  The  impact  on  location  estimation  is  obviou, 
and  requires  no  discussion. 

In  order  to  update  location  estimates,  the  Kalman  Filter  requires 
estimates  of  the  standard  deviation  in  latitude  and  longitude.  These  are 
the  parameters  VLAT  and  VLONG  discussed  in  Section  3.2.5.  With  each 
successive  detection,  these  parameters  are  updated.  Necessarily,  with  more 
information,  i.e.  additional  pass  detections,  the  error  should  become 
smaller.  Similarly,  the  estimation  of  the  BIAS  should  improve  with 

successive  passes  and  hence  the  updated  VBIAS  should  reduce  with  time. 

In  Figure  15,  the  trend  in  the  estimation  of  VLAT,  VLONG  and 

VBIAS  are  illustrated  for  the  two  transmission  sites,  i.e.  the  GSFC  beacon 
and  the  Chicago  area  transmission.  These  data  are  plotted  as  a  percent  of 
the  initial  estimate.  It  is  obvious  that  the  Kalman  Filter  is  working 

quite  well.  However,  it  is  more  interesting  to  note  that  the  biggest  gains 
in  terms  of  reducing  error  occur  in  the  first  three  to  four  detections. 
This  is  significant  since,  referring  to  Figure  10,  the  number  of  occasions 
when  multiple  detections  occur  outside  this  range  are  small. 

As  an  interesting  aside  to  the  above  discussion,  the  linear 

deviation  in  the  estimate  of  BIAS  for  the  two  transmissions  is  also  plotted 
in  Figure  15.  Once  again,  because  the  true  transmission  frequency  was  not 
known,  the  initial  estimate  of  BIAS  was  used  as  the  reference  point.  It  is 
obvious  from  these  data  why  the  assumption  was  made  that  the  GSFC 
transmitter  was  a  test  beacon.  The  deviation  in  the  BIAS  estimate  was 
negligible.  The  Chicago  transmission  is  significantly  different.  While  in 
absolute  terms  the  variation  is  probably  not  significant,  i.e.  1  KHz  in 
121.5  MHz,  the  Kalman  Filter  data  does  point  at  the  positive  drift  in  the 
beacon.  The  other  interesting  conclusion  drawn  from  these  data  is  that  the 
LUT  estimation  of  BIAS  is  good  since  in  effect  the  sample  period  provided  a 
comparison  of  a  test  beacon  (presumably  with  good  transmission 
characteristics)  being  demonstrated  to  have  these  good  characteristics,  and 
a  real  beacon  being  demonstrated  to  have  less  than  ideal  transmission 
characteristics. 

Therefore,  in  this  brief  discussion,  the  impact  of  merging  repeat 
detection  data  through  Kalman  Filter  techniques  has  been  illustrated.  It 
is  readily  apparent  that  the  net  improvement  is  significant  and  most  of  the 
gains  are  made  by  the  third  to  fourth  detection. 


5.0  SUMMARY  COMMENTS/RECOMMENDATIONS 

The  problems  associated  with  the  flow  and  handling  of  SARSAT 
121.5/243  MHz  alert  data  have  been  discussed.  The  nature  of  the  problem 
has  been  characterized  and  methods  to  support  operational  actioning  of 
these  data  have  been  postulated,  studied  and  validated. 

The  objectives  of  this  developmental  study  have  been  achieved.  A 
LUT  to  CMCC  parameter  definition  is  given  and  a  suggested  data  flow 
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methodology  has  been  developed.  The  impact  and  utility  of  the  approach 
discussed  has  been  validated  and  characterized  using  historical  SARSAT 
data. 

It  is  recommended  that  the  designers  and  developers  of  future 
improved  SARSAT  facilities  take  into  account  the  results  of  the  work 
discussed  herein.  Specifically,  it  is  recommended  that  a  cluster  algorithm 
be  built  into  future  LUT  designs  in  order  that  the  requirements  of 
parameter  transfer  definition  be  met.  The  impact  of  having  a  merge 
algorithm  at  the  CMCC  is  well  understood  and  has  been  demonstrated  to 
significantly  improve  data  quality.  Finally,  steps  must  be  taken  to  reduce 
the  volume  of  data  currently  being  presented  to  CMCC  controllers  for 
processing  and  to  the  SAR  community  for  its  action. 

At  the  operational  level,  if  the  methodology  recommended  was 
implemented,  two  significant  outcomes  are  anticipated.  Firstly,  CMCC 
controllers,  with  little  risk  in  the  loss  of  SAR  efficiency,  can  be 
relieved  from  having  to  action  50%  of  the  LUT  generated  data.  Furthermore, 
there  would  be  a  significant  reduction  in  the  amount  of  poor  quality  data 
distributed  to  RCCs  for  their  action.  Rules  are  then  suggested  for 
actioning  the  remaining  data.  In  their  simplest  terms  these  rules  are  as 
follows:  action  all  data  for  which  cluster  sizes  are  greater  than  one  (the 
level  of  action  is  tempered  by  the  quality  of  the  data  as  reflected  in  the 
data  qualifiers);  action  only  those  single  element  clusters  when  the  data 
qualifiers  (Category  and  Q)  indicate  that  the  data  is  good  or  at  least 
mediocre.  The  above  recommended  procedure  is  viewed  as  being  relatively 
conservati ve. 

As  a  final  footnote  to  the  discussion,  the  studies  discussed  and 
documented  herein  have  illustrated  that  technically,  the  Canadian  SARSAT 
facilities  function  extremely  well.  However,  in  terms  of  handling  the 
data,  in  an  analogy  to  a  management  information  system,  they  have  serious 
shortcomings  which  impact  in  a  significant  manner  on  operational 
efficiency.  Recommendations  are  made,  and  approaches  suggested  to  resolve 
these  shortcomings. 
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The  transfer  of  beacon  alert  data  from  the  SARSAT  Local  User  Terminal 
(LUT)  to  the  Canadian  Mission  Control  Centre  (CMCC)  has  shortcomings.  A 
critical  review  of  the  transfer  of  information  between  these  two  SARSAT 
facilities  was  undertaken.  As  a  result  of  this  review,  a  recommended  LUT  to 
CMCC  data  flow  methodology  has  been  developed,  characterized  and  evaluated. 
Implementation  of  the  recommendations  outlined  should  improve  the  operational 
usefulness  of  the  SARSAT  system. 
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